A large scale computer program provides a large number of functionalities that can be invoked by users and other entities (e.g. other programs). Some of these functionalities may have significant impact on the overall operation and performance of the program, while other functionalities may have little or no impact. Because some of the functionalities may give rise to serious consequences, it is desirable to limit access to those and perhaps other functionalities to ensure that only the proper users have access to them.
Many computer programs use a role-based model for controlling access to particular functionalities or components. Role-based access control (RBAC) models determine whether a user is allowed access to a particular component or functionality based on a “role” associated with a user. Typically a user's role includes one or more privileges, and access is determined based on whether the privileges are sufficient to access the desired functionality.
In a computer program that has been implemented using containers, clients provide user authentication and role information to a container in order to access services hosted by the container. User authentication information is validated, and role information is passed to the requested service hosted by the container. If the requested service determines that a role associated with the user contains sufficient privileges to access the requested service, then the client is allowed access to the service.
It is easy to pass role information to a service in a container that supports only one particular type of client. However, in a system in which a container is used to provide common functionality to many different types of user interfaces and external programs, role information cannot be passed to the hosted services in a uniform, consistent manner.
A container that provides services to multiple types of clients has many different connection adaptors, each adaptor intended for use by a different type of client to securely route client requests to services hosted by the container. Information received at the various adaptors may be formatted in a wide variety of ways, as each adaptor may support a completely different protocol. Because each adaptor supports a different protocol, the container must be implemented such that it includes programming logic that allows the container to obtain role information formatted in many different ways from the various adaptors, and to pass the role information to the requested service in a format that is useable by the service to determine whether a user has sufficient privileges to access the service. This programming logic must include code specific to each adaptor in order to support all requests.
Because a container must include programming logic to handle requests from each adaptor, adding a new adaptor to a container requires that new programming logic be added to the container to handle requests from the new adaptor, Maintaining this programming logic in the container to interface with many different adaptors is expensive, and can lead to large amounts of redundant code.
Furthermore, once a session has been initiated between a client and the container, the role of the user cannot change or be updated. In order to change a user's role, the connection to the container must be closed, and then re-opened using new role information.
As the above discussion shows, the current approaches to implementing role-based access control in containers have significant drawbacks. Consequently, an improved approach is needed.